home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group02b.txt / 000155_icon-group-sender_Mon Dec 9 08:31:28 2002.msg < prev    next >
Internet Message Format  |  2003-01-02  |  4KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id gB9FVQg24308
  4.     for icon-group-addresses; Mon, 9 Dec 2002 08:31:26 -0700 (MST)
  5. Message-Id: <200212091531.gB9FVQg24308@baskerville.CS.Arizona.EDU>
  6. From: "Ladv∩┐╜nszky K∩┐╜roly" <aa@bb.cc>
  7. X-Newsgroups: comp.lang.icon
  8. Subject: Re: Icon compiler
  9. Date: Mon, 9 Dec 2002 14:59:55 +0100
  10. X-Priority: 3
  11. X-MSMail-Priority: Normal
  12. X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
  13. X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
  14. To: icon-group@cs.arizona.edu
  15. Errors-To: icon-group-errors@cs.arizona.edu
  16. Status: RO
  17.  
  18. I'm not sure what is derogatory in considering adding a tool to a software
  19. developer's toolchest.
  20. My intention was just the opposite, ie. to express that I had recognised
  21. it's power.
  22.  
  23. > In fact it would probably not be far fetched to say that if everything
  24. that is
  25. > done in C nowadays would be done in Icon, there would not be a noticeable
  26. > difference, and programs would have much more functionality and
  27. attractiveness
  28. > to users.
  29.  
  30. There are situations where one has to handle large amounts of data, say 100k
  31. of elements of any kind.
  32. For such applications, 600s/8s would certainly make a big difference for the
  33. user.
  34. Icon is powerful but clearly not suitable for this sort of tasks.
  35.  
  36. "ernobe" <ernobe@msn.com> az al∩┐╜bbiakat ∩┐╜rta a k∩┐╜vetkez∩┐╜ h∩┐╜r∩┐╜zenetben:
  37. MPG.185ec5e4a40a31c09899a9@news.CIS.DFN.DE...
  38. > In article <3df45481$1_7@news.meganetnews.com>, aa@bb.cc says...
  39. > > Thanks for your answer.
  40. > >
  41. > > > The Icon-to-C (iconc) compiler can produce very fast programs. I
  42. recall
  43. > > once
  44. > > > using it on the Icon versions of uuencode / uudecode ("iiencode.icn"
  45. and
  46. > > > "iidecode.icn" in the IPL) and ran some timing checks. The iconc
  47. versions
  48. > > of
  49. > > > iiencode / iidecode were over 3 times as fast as the interpreted
  50. (icont /
  51. > > > iconx) versions. More surprisingly, I found that the iconc programs
  52. were
  53. > > > actually faster than native C uuencode / uudecode programs that I was
  54. > > using
  55. > > > at the time!
  56. > >
  57. > > Well ... I have this Fibonacci test for benchmarks. With MS C ++ it
  58. takes 8
  59. > > secs to calculate the result for 40 as input and for Icon it takes about
  60. 600
  61. > > secs. Now with even 3 times speed improvement, it'd still be 200 secs
  62. for
  63. > > Icon. Given that, I think it's very exaggerated to say Icon programs can
  64. be
  65. > > faster than C. However slow compared to C, I do recognise Icon's power
  66. and
  67. > > I'm considering adding it to my software toolchest.
  68. > >
  69. > >
  70. >
  71. > Icon is meant to enable people to code more efficiently than in C.  Given
  72. that
  73. > it is people who produce computer programs, not computers programmed in C,
  74. to
  75. > refer to it as simply another tool in ones toolchest seems rather
  76. derogatory.
  77. > In fact it would probably not be far fetched to say that if everything
  78. that is
  79. > done in C nowadays would be done in Icon, there would not be a noticeable
  80. > difference, and programs would have much more functionality and
  81. attractiveness
  82. > to users.
  83. > I don't know much about computers myself, I can't really tell what an Icon
  84. to C
  85. > translator is, but since there is a compiler which produces executables
  86. and is
  87. > itself coded in C, it would probably take just someone well grounded in C
  88. to
  89. > make a translator.  Of course the reason it hasn't is obvious to those
  90. familiar
  91. > with the problems of implementing a low-level language across several
  92. platforms
  93. > and OS.  Until such time as there is more agreement about such platforms
  94. and OS
  95. > to make generalized low-level language programming efficient, Icon
  96. programmers
  97. > are well advised to familiarize themselves with C or Assembly, and
  98. optimize
  99. > their programs themselves.
  100. > I think functions programmed in C can be called, I don't know if it is
  101. possible
  102. > to add machine code, but it sounds like something a-lot simpler to
  103. accomplish
  104. > than in most other computer languages.  It is a great way to learn
  105. Assembly, I
  106. > think, if one could learn how to optimize generators.
  107. >
  108. >
  109. >
  110. > --
  111. > my esoteric links:
  112. > http://www.costarricense.cr/pagina/ernobe/
  113.  
  114.  
  115.